今天要來介紹一個很多工程師都會有感的痛點：不是不想寫單元測試，是常常忙到最後只剩下「之後再補」，然後那個「之後」就跟減肥一樣，永遠是明天開始啊~

筆者這次實測的是 GitHub Copilot 在 VS Code 裡，怎麼用 /setupTests、/tests、還有 /fix 來修復 Python 單元測試結果。原本以為它可以一條龍幫我處理到漂漂亮亮，不過不同的Mode用 /tests 寫出的單元測試也不同，還要自己跳下去測過一輪啊，找出自己合用的

🧪 先把測試環境架起來：/setupTests 真的有省事

筆者一開始先示範 /setupTests。這個指令的概念很簡單，就是丟下去之後，Copilot 會嘗試辨識你的專案語言、推測適合的測試框架，然後幫你建立基本測試環境。因為筆者 demo 的 source code 是微軟提供的 Python 範例，所以它有偵測到這是 Python 專案，接著去找 Python 可用的 test framework。這時候它會給選項，讓你挑 pytest 或 unittest 之類的路線。

同樣的 slash command，不同模型跑出來的結果會不一樣。有時候它會給兩個選項，有時候只給一個，像筆者切換模型後，它就直接覺得 pytest 最優，不囉嗦，直接單押 pytest 給我看~

這件事其實很重要，因為很多人會以為 command 是固定規則、固定輸出，但實際上不是。同一句話、不同模型、不同結果，另外原本以為便宜模型只是慢一點，結果有時候不是慢，是直接把你帶去別條路。對熟的東西拿來省錢可以，對不熟的東西，筆者建議還是使用貴的模型阿~ 而且有時候看似便宜，結果跑超久、修超多次，最後總成本也未必比較省。

接著它幫筆者產出基本測試檔案後，筆者直接跑Hello World測試。結果第一個坑馬上出現：VS Code 找不到測試檔案。

⚙️ 第一個坑：VS Code 預設沒抓到 Python 執行環境
這裡超容易卡關，尤其是第一次玩的人。筆者實際踩到的狀況是，VS Code 的測試功能是預設是 C# ，結果現在筆者是在跑 Python 測試，它卻沒用到正確的 Python interpreter。解法不難，就是去選正確的 Python 執行環境。筆者這邊選的是 Python 3.13.7，切好之後再跑一次，測試就正常出現了。

📝 /tests 怎麼用
環境好了之後，筆者就開始針對單一檔案請 Copilot 寫單元測試。這邊用法也不難，直接對目標檔案下 /tests 就好，現在不會直接幫你生檔，要自己 Keep / 存檔如下圖。

接著筆者跑這支新生成的測試，果然，AI 不會讓你太無聊，它寫出來的測試出錯了 😆

🐛 /fix 實測：不是不能用，但沒有想像中那麼神
錯誤一出來，筆者先點開 test message 看它到底炸在哪。這次是很典型的參數問題：它少了 book_id 相關參數，把錯誤訊息跟測試內容一起當上下文，試著用 /fix 去修。老實說，當下看起來它像有修對，右側也產出一坨看起來很合理的修改，心裡還想說「喔喔喔，這次有喔」🙂

結果呢？再跑一次，還是錯。

所以這段實測下來，/fix 並不是那麼好用。

✅ 筆者推薦招式
遇到測試失敗時，直接把錯誤訊息 + 目標檔案 + 測試檔案 一起丟給模型，直接打 fix it。尤其是模型夠強的時候，這招幾乎是萬用。

更多實作請參考完整版影片

📌 今日結論

💸 不熟的領域別硬省模型費用。便宜模型有時候不是省，是慢慢陪你繞遠路。

🛠 實務上應用: /tests 能加速起手式，/fix 不一定萬用；用"fix it" + 貴的模型或許更省事。